Computer systems are often comprised of components, where a component typically is embodied as an execution domain in which software may execute in isolation from other components, potentially affected by only the other components on which there is an acknowledged trust dependency. An example is a layered computer platform. With layering implemented in hardware, software, or a combination of hardware and software, each layer will consist of one or more components. The layered computer platform architecture is often constructed with a hierarchical privilege model. Each layer is more privileged than the layers above it. A layer having higher privilege is allowed to control and potentially corrupt the layers above it that have less or lower privileges. In such layered computer platform architecture, components in the upper layers are trust-dependent on components in the layers below them. In general, a component is trust-dependent on another component if it relies on another component in ensuring the integrity or confidentiality of its code or data. The Trusted Computing Group (TCG) has developed standards to ensure the security and integrity of a computing platform. The current standards do not address systems with trust dependencies.
According to TCG standards, there are Trusted Building Blocks (TBBs) for a platform which form the root of trust for the platform. These include a Trusted Platform Module (TPM) and a Core Root of Trust for Measurement (CRTM). A CRTM is the root of trust from which integrity measurements begin within a trusted computer platform. The TPM provides secure storage and reporting for the integrity measurements and other data. The platform manufacturer provides CRTM logic for each trusted computer platform. The CRTM logic can be changed, however, changes can only be made by the manufacturer of the computer platform. In addition, the changes can only be made under controlled conditions. TCG specifies two types of CRTM: a Static CRTM (S-CRTM) and a Dynamic CRTM (D-CRTM).
In platforms with an S-CRTM, the S-CRTM is the first module to be executed after the platform is reset. The S-CRTM computes an integrity measurement of the next code in the boot sequence (e.g., using a one-way hash algorithm (e.g., SHA-1)), and records the integrity measurement in a Platform Configuration Register (PCR) within the TPM. Boot control is then transferred to the code that was measured, which in turn measures and records the next code that is loaded. This process is continued and repeated until the platform is booted and applications of the platform are running.
In computer platforms with a D-CRTM, the D-CRTM may be invoked at any time after the platform is reset. The D-CRTM sets up a trusted computing environment, measures the first code to run in that environment and stores that measurement in a PCR within the TPM. The D-CRTM asserts “locality”, which provides an indicator to the TPM that the measurement came from a D-CRTM rather than an S-CRTM, and the TPM divides its PCRs among localities asserted by the D-CRTM. Subsequently, code continues to be booted in the trusted computing environment, with the code that is loaded into the computer platform being integrity measured and the measurements recorded in the TPM.
As part of the integrity measurement process, a measurement log is maintained by the components in the chain of trust. The measurement log contains information on what measurements were taken, in what order, and in which of the PCRs the measurements were stored.
A computer system that is comprised of components may have multiple TBBs, one for each component, and there may be trust dependencies among the components. Thus, a PCR in one component may be trust-dependent on PCRs in another component. For TPM operations that use PCRs, methods are needed to define and resolve the trust dependencies.